Cream of the Crop 1/Cream of the Crop 1.iso/PROGRAM/FLEXFILE.ARJ/FLEXINFO.EXE/BRIEF.TXT

Text File | 1991-10-22 | 6KB | 133 lines

                     FlexFile Documentation Disk
                        Ganahl Software, Inc.
                         Copyright (c) 1991


This file is included as an introduction to FlexFile.  If you prefer a more
in-depth discussion of the workings of FlexFile, or if you want examples of
functions that are included with FlexFile, you will want to read the
documentation file (FlexFile.doc) or view the Norton Guides database
(FlexFile.ng).



FlexFile's primary purpose is to eliminate the problems associated with
Clipper's memo fields while retaining their ease of use.  In addition,
FlexFile can save arrays to its improved version of a "memo-field" (even
Clipper 5.0 nested arrays).

   FlexFile addresses the four major problems that plague Clipper's
   memo-fields:

   First, FlexFile reuses all unused space.  If your user edits a memo (or
   deletes elements of an array) making it smaller, FlexFile is aware of
   every byte of the excess space and will use it later for new data.  This
   feature totally eliminates the file bloat which is so characteristic of
   Clipper's DBT files.

   Second, FlexFile does not allocate space in blocks.  Instead, each item
   stored requires only the space for its own length plus a six byte header
   that FlexFile uses for management.  This is in great contrast to
   Clipper's memo-fields which require a fixed block size of 512 bytes.

   Third, FlexFile's file size is limited only by your disk space.

   Finally, FlexFile can store any valid Clipper data.  This includes
   arrays, character strings, dates, numerics, and logicals.  In addition,
   the content of character data is not limited.  It is, therefore,
   possible to store SAVESCREEN() variables or any other binary data that
   you use.

The savings associated with FlexFile's use depend largely on what data is
being saved.  For example, the smaller the average size of your data the
larger percent savings FlexFile will realize over a "packed" DBT file (i.e.
a DBT file that has not undergone any REPLACEs or DELETEs).

Once you begin to REPLACE or DELETE data, the opposite becomes true and the
savings are greater for larger data items.




FLEXFILE'S ADVANCED FEATURES


Introduction

FlexFile's primary function is to replace Clipper's memo-field/DBT system
with a simple and efficient Variable Length Field engine. However, FlexFile
not only relieves the programmer of the excruciating limitations imposed by
Clipper's memo-fields, but also adds significant flexibility to the DBF
file format without sacrificing simplicity.  In addition, FlexFile offers
data compression and encryption.

Saving Arrays

One of FlexFile's most powerful features is its ability to save and
retrieve multi-dimensional arrays.  To understand why, consider the simple
example of storing telephone numbers in a customer file.  Most businesses
require several numbers: voice lines, fax lines, data lines, car phone
lines and others.  However, the developer must make a decision to either
limit the number of fields in the customer file or build a related DBF file
with an index. With FlexFile, however, an array of telephone numbers can be
saved to one field in your DBF.  Those customers who require many telephone
lines do not have an imposed limit and those customers who have fewer lines
do not waste any disk space.

Compression/Encryption

FlexFile's data compression has great advantages over standard compression
utilities. First, FlexFile's compression occurs on a field-by-field basis.
While the file always remains compressed, each field is un-compressed only
as it is brought into memory. Second, FlexFile was designed to work from
within Clipper and, lets face it, even Clipper 5.0 doesn't give us lots of
extra memory to work with.  FlexFile requires less than 6K bytes of memory.
Most compression techniques require substantially more. As an added
benefit, FlexFile's compression also acts as encryption.  As is typical of
the entire FlexFile library, the speed of the compression is outstanding.


FlexFile on a Network

FlexFile typically requires no special network considerations beyond
Clipper's RLOCK().  If you acquire an RLOCK() on a record in a DBF file
that has a pointer-field, no other user will have WRITE access to that
record.  Behind the scenes, FlexFile will lock and unlock its own internal
tables automatically requiring no programmer intervention.

Multiple DBV files

The use of FlexFile's Variable Length Field (VLF) files was designed to
parallel the use of DBF type files.  Specifically, the system is made up of
work areas that are used to manage the VLF files in exactly the same manner
as Clipper uses work areas to manage DBF files.

For example, you can V_SELECT(1) and then V_USE() a file in area one, and
then V_SELECT(0) the next available work area and V_USE() another file
there.  It should be noted that FlexFile's work areas are mutually
exclusive from Clippers DBF work areas.

FlexFile alone

FlexFile can also be used without the help of a DBF.  This feature is
particularly helpful when your application first starts up.  At this point
you usually face the problem of gathering system information: Color
schemes, users network rights, communication ports, screen size settings,
default directories, ..., the list could go on and on. None of this
information goes well in a DBF file because it is non-repetitive in both
type and length.  So, let FlexFile keep it in an array (Clipper 5.0 multi-
dimensional arrays are excellent for this).


FlexFile and Graphics

FlexFile can save any binary data including graphics images. Therefore, it
works well with graphics packages. To understand this advantage, consider a
prison management system that required a picture of each inmate.  You could
have a DBF record for each inmate and one of its fields could be called
<mug_shot>.  Currently, most graphics packages require that each image be
stored in a separate DOS file.  With FlexFile, however, the images can all
be stored in one file.